<html>
<head><meta charset="utf-8"><title>Muckable Pitfall - Language-Level Layout Instability · project-safe-transmute · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/index.html">project-safe-transmute</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Language-Level.20Layout.20Instability.html">Muckable Pitfall - Language-Level Layout Instability</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="218336402"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Muckable%20Pitfall%20-%20Language-Level%20Layout%20Instability/near/218336402" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Language-Level.20Layout.20Instability.html#218336402">(Nov 30 2020 at 19:50)</a>:</h4>
<p>In our zulip-current design, implementing the <code>Muckable</code> traits denotes that the subject type has a SemVer stable layout. Crucially, the ordering of fields must be totally fixed.</p>
<p>This is a tractable guarantee for <code>#[repr(C)]</code> types (whose layout is wholly specified), but not necessarily for <code>#[repr(Rust)]</code> types (whose layout will probably never be wholly specified).</p>
<p>For instance, consider a future <code>#[repr(Rust)]</code> type for which all layout qualities <em>except</em> field order is specified. Such a type cannot possibly be <code>Muckable</code> — that connotes a SemVer layout promise that the type's author simply cannot make.</p>
<p>Field order instability is just <em>one</em> potential way this issue might play out. There are others. For instance, the layout guarantees of <code>#[repr(C)]</code> types dictates that padding bytes are uninitialized. This isn't promised for <code>#[repr(Rust)]</code> types, and there are compelling reasons for zeroed-initialized padding. We can imagine a <code>#[repr(Rust)]</code> type for which all layout qualities <em>except</em> padding (un)initialization is specified.</p>



<a name="218336463"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216762-project-safe-transmute/topic/Muckable%20Pitfall%20-%20Language-Level%20Layout%20Instability/near/218336463" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jack Wrenn <a href="https://rust-lang.github.io/zulip_archive/stream/216762-project-safe-transmute/topic/Muckable.20Pitfall.20-.20Language-Level.20Layout.20Instability.html#218336463">(Nov 30 2020 at 19:51)</a>:</h4>
<p>TL;DR: <code>Muckable</code> is tuned <em>really</em> well for <code>#[repr(C)]</code> types, but not for reprs with some language-level layout instability.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>